The previous heading seemed… incomplete.

Unrelated change, but it's something many editors do automatically. I can remove it, but I imagine others will run into the same thing.

You are not the only one. We should maybe lint for trailing whitespace.

I'm not sure I agree with this principle. This assumes that tracking this information is free. I don't think it necessarily is. And with the current design only those interested in the information pay for having it tracked.

(This doesn't mean that FetchObserver/FetchMonitor can't expose the information directly, because obtaining such an object could be considered the opt-in.)

That's fair.

Does this need to be a note?

I did it to separate the rule from the explanation of the rule, since the explanation is non-normative. But this spec doesn't have such a strict divide between normative and non-normative. But I don't mind either way, happy to go with whatever you think.

I'm not sure if I understand this paragraph...

Or if it's completely accurate. There are a few events that are fired asynchronously, e.g. slotchange. The state on the event target might have been updated when the event listener is triggered.

I'm not sure that I'm following this sentence. I don't know what "retuning" means in this context.

Do you mean that people might want to consider adding a function to EventTarget to get the state instead? Or are you saying that you might add a function that flips the EventTarget into a mode that tracks the state, so that the cost is only paid when the state is needed?

It would really help if there was a concrete example of this problem. I'm having a little trouble coming up with one.

Calling the function returns the EventTarget, at which point the implementation will have to track the state (if it's exposed on the target instead of the event).

Yeah, so instead of something like:

self.pageDataUsage.addEventListener('change', () => {
  console.log(self.pageDataUsage.bytesReceived);
});

…where self.pageDataUsage.bytesReceived will need to be continually updated so it can be synchronously accessed by any code running in the doc/worker, you'd do something like:

self.pageDataUsage.addEventListener('change', (event) => {
  console.log(event.bytesReceived);
});

…where the data is only available to listeners of the change event, so if there are no listeners, the underlying operation to get bytesReceived doesn't need to happen. Or, alternatively, "return an {{EventTarget}} from a function":

const pageDataUsage = await self.monitorDataUsage();

pageDataUsage.addEventListener('change', () => {
  console.log(pageDataUsage.bytesReceived);
});

In this case, it's the call to monitorDataUsage() that signals interest, and GC of pageDataUsage will signal disinterest.

The second model gives you an object representing current state that can be passed around.

retuning is a typo in the PR. I'll fix that once we figure out the right wording.

This approach still assumes that the dataUsage.bytesReceived is maintained, but only when you ask for it. A truly expensive API might use:

self.addEventListener('dataUsage', e => {
  console.log(e.bytesReceived);
});

No need to include that though.

Wouldn't that be equally expensive as the function example? I guess removeEventListener is a more immediate signal of disinterest vs waiting for GC on the object you get back from the function.